home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 774 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.9 KB
  1. Path: grafix.xs4all.nl!john.hendrikx
  2. Date: Sun, 07 Jan 96 16:20:44 GMT+1
  3. Newsgroups: comp.sys.amiga.misc
  4. Distribution: world
  5. Subject: Re: Hombre history - RISC selection
  6. MIME-Version: 1.0
  7. Content-Type: text/plain; charset=iso-8859-1
  8. Content-Transfer-Encoding: 8bit
  9. From: john.hendrikx@grafix.xs4all.nl (John Hendrikx)
  10. Message-ID: <john.hendrikx.44pj@grafix.xs4all.nl>
  11. Organization: Grafix Attack BBS Holland
  12.  
  13. In a message of 06 Jan 96 Michael Van Elst wrote to All:
  14.  
  15.  >> No really?  I'm glad you brought this to my attention.  Next you'll be
  16.  >> telling me that HAM8 is also better than '23-bit' screens as it is
  17.  >> -possible- to use the full 24-bit palette with HAM8 (if the picture was
  18.  >> large enough).
  19.  
  20.  MVE> I am telling you that it is better than 16bit. Nothing more. With HAM
  21.  MVE> you get some degree of fringing, with 16bit you get larger visible
  22.  MVE> quantization errors. Both deficiencies cause about the same amount of
  23.  MVE> image degradation.
  24.  
  25. Fringing is much worse than a simple quantization error.  HAM8 actually causes
  26. pixels which have wrong colors (wrong HUE) and wrong brightness.
  27.  
  28.  An example of wrong HUE and brightness:
  29.  
  30. TrueColor data: $ff ff ff  $e9 e9 e9
  31.  
  32.   HAM displays: $ff ff ff  $ff e9 ff
  33.  
  34. Not only is the color too bright, it also isn't gray anymore as it should be. 
  35. This kind of errors happen all the time with HAM.  With 16-bit the result will
  36. atleast be consistent (no ugly pixels in places messing up the whole pic) and
  37. the errors will never exceed a certain limit (the error will never be more than
  38. $04 02 04 -- try getting that with HAM8)
  39.  
  40.  >> giving better results.  Try dithering HAM from right to left for example
  41.  >> -- next to impossible, but with 'normal' displays this can make quite a
  42.  >> difference.
  43.  
  44.  MVE> Does it ? :)
  45.  
  46. Yes, if you dither all odd lines from left to right and even lines right to
  47. left the dithering will be better.  If you only draw the lines from left to
  48. right (in HAM you're forced to do this) then the quantization errors will
  49. slowly shift to the right of the picture.
  50.  
  51.  >> (just think of it; if we had 16-bit screens for 4 years now instead of
  52.  >> HAM8, it would have meant that v39 graphics library would already have
  53.  >> support for true color screens (which is basicly one of the biggest things
  54.  >> missing in the current graphics library...))
  55.  
  56.  MVE> Which is a completely different issue. graphics doesn't support HAM8
  57.  MVE> rendering either. So what ?
  58.  
  59. HAM8 is simply not supported as it is impossible to use a display mode like HAM
  60. for graphics rendering.  Even doing a simple thing like drawing a line gives
  61. enormous problems.  C= surely would have made graphics use 16-bit if it was
  62. available instead of HAM.
  63.  
  64.  >> HAM (Hold And Modify):
  65.  >>  a hack to display more colors because the OS and Hardware are
  66.  >>  unable to handle the real thing.
  67.  
  68.  MVE> The real thing is a 24bit display, not a 16bit one.
  69.  
  70. The real thing for me is a Chunky True Color screen, and 16-bit fits that
  71. description.
  72.  
  73. Grtz John
  74. -- Via Xenolink 1.981, XenolinkUUCP 1.1
  75.